Amiga Collections: Franz PD

home *** CD-ROM | disk | FTP | other *** search

/ Amiga Collections: Franz PD / Franz PD Disk #324 (1994-04)(Rhein-Sieg-Soft).zip / Franz PD Disk #324 (1994-04)(Rhein-Sieg-Soft).adf / VideoText3.5 / LiesMich < prev next >

Wrap

Text File | 1994-04-01 | 36KB | 770 lines

LiesMich-Datei zum Programm VIDEOTEXT V3.5 Stand: 31.03.94 INHALT 1. Allgemeines/Hardwareanforderungen 2. Leistungsmerkmale 3. Installation 4. Erste Inbetriebnahme 5. Bedienung 6. Argumente beim Programmstart 7. Dienstprogramm VTview 8. Was Sie für mich tun können WARNUNG ------- "VIDEOTEXT" KANN AUSGABEDATEIEN ERZEUGEN, ÜBERSCHREIBEN, UND TEXT AN BESTEHENDE DATEIEN ANHÄNGEN. DER DABEI VERWENDETE DATEINAME IST STÄNDIG SICHTBAR IM PROGRAMMFENSTER ANGEZEIGT. FÜR DENNOCH AUS DATEIOPERATIONEN ENTSTEHENDE SCHÄDEN KANN ICH KEINE VERANTWORTUNG ÜBERNEHMEN. EBENSO MUß ICH JEDE VERANTWORTUNG FÜR SCHÄDEN DURCH PROGRAMMABSTURZ ABLEHNEN UND KANN LEDIGLICH VERSICHERN, DASS ICH SELBST DAS PROGRAMM TÄGLICH BENUTZE, UND DASS VON DEN BISLANG AUFGETRETENEN FEHLERN ALLE SCHWEREN FEHLER (D. H. SOLCHE IN ZUSAMMENHANG MIT ZEIGERN) IN DER VORLIEGENDEN PROGRAMMVERSION BESEITIGT SIND. 1. Allgemeines/Hardwareanforderungen ==================================== Das Programm VIDEOTEXT steuert einen Philips Videotext-Decoder SAA 5246 an, um Videotext-Seiten in den Amiga einzulesen, zu betrachten und ggf. in Dateien abzuspeichern. Die vorausgesetzte Hardware entspricht dem Projekt aus der C'T 3/92 (& 2/92, 11/91) und umfaßt im einzelnen: - I²C-Bus Interface am RS232-Port des Amiga (Beschreibung siehe Hardware.doc) - Decoderbaustein SAA 5246 nebst Beschaltung, mit den Schnittstellen I²C-Bus und FBAS-Bildsignal-Eingang (in Hardware.doc *nicht* beschrieben, da relativ aufwendig, nur Literaturhinweise) - eine FBAS- (oder BAS-) Signalquelle, i. a. ein Fernseher oder Satelliten- receiver mit SCART-Ausgang (hat man oder hat man nicht, extra neu anschaffen lohnt wohl kaum :-) Ganz deutlich gesagt: Ich setze eigentlich voraus, daß Sie diese Hardware (mit Ausnahme vielleicht des I²C-Bus Interfaces) bereits besitzen, und ich kann insbesondere Anfängern nicht ernsthaft empfehlen, sie anhand meiner Dokumentation aufzubauen zu versuchen. 2. Leistungsmerkmale ==================== 2.1 Was kann Standard-Videotext? -------------------------------- Videotext an sich ist bereits eine faszinierende Informationsquelle. Um ARD/ZDF zu zitieren: "Auf rund 400 Tafeln können Sie sich während der gesamten Sendezeit [...] über das weltweite Geschehen informieren. Videotext informiert Sie über das Neueste aus Bonn, Moskau oder Washington, den Kulturskandal, den Leichtathletik-Rekord oder das Tor in der Fußball-Bundesliga. Auch Zwischenstände der Aktienkurse und die Wettervorhersage finden Sie im Programm." Große Schwäche ist aber die Decoder-Hardware beim Fernsehzuschauer, die mit typischerweise nur 8 Seitenspeichern eine echte Cache-Funktion nicht wahrnehmen kann. Sie zwingt den Benutzer viel zu häufig, Seiteninhalte zu überschreiben, auf die er eigentlich noch nicht verzichten möchte, und die Möglichkeit, alte Seiten erst während des Wartens auf neu angeforderte zu lesen, ist auch ziemlich eingeschränkt. Und als ganz grotesk habe ich immer die seltsame Institution der "Unterseiten" empfunden, die dem Benutzer im Minutentakt neue Seiteninhalte vorsetzt bzw. ihn 2 bis 5 Minuten (je nach Unterseitenanzahl) auf einen bestimmten Seiteninhalt warten läßt. Ganz interessant sind die Lösungsansätze der Industrie: Decoder mit Speicher für 512 statt 8 Seiten, und, bereits am Markt durchgesetzt, TOP-Videotext (Table Of Pages). Letzteren habe ich leider noch nie in Aktion gesehen, soweit ich verstanden habe, geht es aber darum, ein Inhaltsverzeichnis im Dekoder zu erstellen, das den Zugriff auf die diversen Indexseiten ersparen soll. 2.1 Was kann mein Programm? --------------------------- Die oben genannten Nachteile von Videotext lassen sich mehr oder weniger überwinden, wenn ein Computer (z. B. ein Amiga :-) die Kontrolle über den VT-Decoderchip erhält: mehr Speicher für Seiten, bessere Bediensoftware, zusätzlich die Möglichkeit, Seiteninhalte zu sichern, auszudrucken und weiter zu bearbeiten. (Statt vielen Zeitungsausschnitten eine große ASCII- Datei mit den interessantesten Meldungen des Jahres?) Nun zur Sache, was hat mein VIDEOTEXT-Programm zu bieten: - beliebig viele Seiten einlesbar (dynamisch verwaltete verkettete Liste) - gleichzeitige Suche nach bis zu vier Seitennummern, wobei zu keinem Zeitpunkt übrige Bedienfunktionen blockiert werden - Warteschlange für bis zu 15 angeforderte Seitennummern - Konfigurationsdatei, die jedem Sender bis zu 19 wichtige, häufig gebrauchte Seitennummern zuordnet - unterstützt alle 8 Farben, VT-Grafikzeichen sowie verdeckte und doppelthohe Schrift - Speichern als ASCII-Text, IFF-Bild oder VT-Code, letzterer kann vom Dienstprogramm "VTview" gelesen angezeigt werden - VT-Untertitel können in einer Protokolldatei gesammelt werden - Testmodus: Bus-Status, FBAS- und VT-Signalqualität, laufende VT-Uhr - Übersicht über alle ausgestrahlten VT-Seiten möglich - Einlesen einer Seite in ca. 0.2 sec - Bildschirmausgabe: ca. 1 Seite/sec, auf Kosten unvollständigen Seitenaufbaus auch beliebig schnelleres Durchblättern möglich - vollständig tastaturgesteuert (außer dem Filerequester der req.library) - läuft unter 1.3 und 2.0 - keine 2.0-Features, aber immerhin Unterstützung von CLI- und Workbench- Startargumenten 3. Installation =============== VIDEOTEXT benötigt - einen eigenen Font: "videotext/9" in FONTS: - dementsprechend auch die "diskfont.library" in LIBS: - die "req.library" in LIBS: Keine dieser drei sind unbedingte Vorraussetzung dafür, daß das Programm startet. Ohne den eigenen Font liefert es aber recht jämmerliche Ergebnisse. Dafür ist die mitgelieferte Skriptdatei "AssignFonts" gedacht, sie verlegt halt FONTS: in das VideoText-Verzeichnis UND, bei nochmaliger Ausführung, nach SYS:Fonts/ zurück (jaha!). Das andere Skript, "Install", installiert den Font in FONTS: und die "req.library" in LIBS:. Darüber hinaus unterstützt VideoText eine Sender/Seiten-Konfigurationsdatei - "VT.config" in S: oder im aktuellen Verzeichnis die Sie vermutlich noch selbst erweitern und abändern wollen (in Abschnitt 5.4 beschrieben). 4. Erste Inbetriebnahme ======================= Wenn die Hardware richtig angeschlossen ist und der Font und die Libraries installiert sind, doppelklicken Sie einfach auf das Programm-Icon, und es müßte folgendes passieren: 1. Das Programm öffnet seinen Screen und baut ein paar leere Textfelder auf, unter "Jobs:" wird die Seitennummer 100 eingetragen und rückt gleich darauf ins Feld "Seitensuche:" auf 2. nach einer Weile (<< 1 Minute) müßte Seite 100 eintreffen und am Bildschirm angezeigt werden Wenn das Programm überhaupt nicht starten sollte, deutet das auf ein ziemlich grundsätzliches Problem hin, z. B. zu wenig Speicher. Versuchen Sie in diesem Fall, das Programm vom CLI aus zu starten. Entweder es funktioniert jetzt (unwahrscheinlich, wenn es von der Workbench aus nicht geklappt hat), ODER Sie erhalten jetzt wenigstens eine Fehlermeldung vom KICK-Pascal Laufzeitsystem. Fehlerhafte Installation von Font oder Libraries kann übrigens nicht die Ursache eines solchen Totalausfalls sein: das Fehlen von "videotext/9" oder der "diskfont.library" wird lediglich mit einem Alert gemeldet, eine fehlende "req.library" sogar stillschweigend übergangen. Startet das Programm, aber es treffen auch nach einigem Warten keine Seiten ein, so drücken Sie einmal "t", um den Testmodus zu aktivieren. Der Text im Statusfeld oben in der Mitte des Schirms müßte jetzt weiß aufleuchten, und in 5 Schriftfeldern sollten Statusinformationen erscheinen: Bus: Steht hier "OK", so bedeutet das, daß die Kommunikation mit dem Videotext-Decoder einwandfrei funktioniert. Sie können sich sofort den Meldungen in den übrigen Statusfeldern zuwenden. "Tot" bedeutet dagegen, daß der Decoder nicht einmal auf seine Adresse antwortet. Überprüfen Sie in diesem Fall alle Steckverbindungen (aber bevor Sie ggf. etwas ändern, erst den Rechner ausschalten!), und machen Sie sich schon einmal mit dem Gedanken vertraut, daß irgendwo in ihrer Hardware ein Schaltungsfehler stecken könnte. Eine andere Erklärung wäre noch, daß sie einen beschleunigten Amiga besitzen, (z. B. A1200, A3000, A4000 oder entsprechende 680x0-Turbokarte), so daß der Bus zu schnell läuft. Sie müssen die Busroutine dann über das Programmstart- Argument BUSDELAY entsprechend Ihrer Rechenleistung bremsen. Lesen Sie dazu Abschnitt 6. Wenn im Schriftfeld schließlich "NAK" steht (gesendete Datenbytes wurden nicht quittiert), oder die Anzeige zwischen verschiedenen Texten hin- und herflackert, so ist das ein ziemlich sicheres Zeichen für zu hohe Busfrequenz - oder für ein EMV-Problem. Haben Sie mich vielleicht zu wörtlich genommen und einen Bus aus 50 m Klingeldraht gelegt? Das wäre tödlich. Versuchen Sie es mit einem einen kürzeren Bus (1 - 2 m), wozu der Decoder notfalls auch zunächst von der Videoquelle getrennt werden kann: Die Busfunktion läßt sich auch prüfen, während der Decoder kein Videosignal empfängt. TV: So, der I²C-Bus ist also OK? In diesem Feld erfahren Sie dann, ob der Decoder an Pin 8 ein einwandfreies Videosignal empfängt ("ja"/"nein"). Ziemlich narrensicher, das vom SAA 5246 verwendete Kriterium dürfte das regelmäßige Eintreffen von Bild- und Zeilensynchronisations-Impulsen sein. Diese und die folgende Information stammen übrigens aus dem Statusregister R11B des SAA 5246. Beim Vorgängermodell SAA 5243 (aus welchem Fernseher haben Sie *das* uralte Ding denn ausgeschlachtet ???) ist dies Register nicht vorhanden, so daß in beiden Feldern "Unfug" stehen dürfte, d. h. zwar ja oder nein, aber ohne jede Aussage über die tatsächliche Signalqualität. VT: Wenn der Decoder meint, ein Videotext-Signal zu empfangen, steht hier ein "ja". Wenn die Anzeige "nein" lautet oder flackert, fehlt das VT-Signal oder ist stark verrauscht. Mögliche Ursachen: Kein Sender eingestellt, Sender strahlt keinen Videotext aus (z. B. Pro 7) oder die Empfangsqualität ist schlecht. In letzterem Fall muß das Bild noch nicht einmal sichtbare Mängel aufweisen. Die Datenrate des Videotext- Signals ist mit ca. 7 MBit/s nämlich höher, als man in den 5 MHz Bandbreite, die dem Fernsehbild normalerweise zugestanden werden, überhaupt unterbringen kann. So ist z. B. aus Videoaufzeichnungen, auch wenn sie noch so einwandfrei aussehen, für gewöhnlich kein Videotext mehr decodierbar. VT-Uhrzeit: Hier steht die Uhrzeit, wie sie vom Decoder laufend oben rechts in die Seite eingeblendet wird. Prima, um die Armbanduhr danach zu stellen, aber auch, um die Qualität des Videotext-Signales etwas genauer zu beurteilen. Wenn hier im Prinzip die Uhrzeit lesbar ist, aber häufig wirre Zeichen vorbeiflackern, ist das Videotext-Signal bereits zu schlecht, um noch wirklich von Nutzen zu sein: Wenn überhaupt noch Seiten gefunden werden, so fehlen ihnen haufenweise Zeichen oder sogar ganze Zeilen. Die Ursache dürfte die Antennenanlage am verwendeten Fernseher sein (konnte ich z. B. mit meiner Zimmerantenne erleben), oder (wenn diese über jeden Zweifel erhaben ist, z. B. Satellitenantenne oder sogar Kabelanschluß) das Videosignal muß einen zu weiten Weg vom Fernseher zum Decoder zurücklegen. Wie weit genau man ein Videosignal spazieren führen darf, weiß ich nicht, aber bei der üblicherweise verwendeten NF-Leitung würde ich 2 - 3 m noch für unbedenklich halten. Sys: Die Amiga-Systemzeit. Hat für diesen Test nichts zu sagen. 5. Bedienung ============ Alle Kommandos werden über die Tastatur gegeben. 5.1 Aufrufe von Sonderfunktionen -------------------------------- Help: Zeigt einen Hilfstext an, in dem alle Tastenbelegungen kurz erklärt sind. i: Information über das Seitenangebot. Der Decoder wird auf den Empfang von Seite *** programmiert, was zur Folge hat, daß er JEDE gesendete Seite einzulesen versucht. Das sind ca. 15 Seiten pro Sekunde, und am Fernseher sieht das sehr spektakulär aus (das kann höchstens Commander Data lesen :-). Was der Amiga dabei gerade schafft, ist einen Blick auf die durchlaufenden Seitennummern zu werfen und alle Nummern, die ihm dabei unterkommen, in einer Übersicht darzustellen. Gelegentliche Fehler (Quote ca. 1 %) sind unvermeidlich, da nicht sichergestellt ist, daß die Seitennummer sich nicht während des Lesevorgangs ändert. Wenn hier also Seitennummern gefunden werden, die laut Inhaltsverzeichnis gar nicht existieren dürften, hat wahrscheinlich das Inhaltsverzeichnis recht. Trotzdem ist die Übersicht ganz interessant, z. B. sieht man, in welcher Reihenfolge die Seiten einrollen, wie lang ungefähr ein Seitenzyklus dauert, und wo "kahle Stellen" unter den möglichen Seitennummern sind (z. B. sind bei ARD/ZDF das 700er und das 800er Magazin völlig unbenutzt). Für diese beiden Sonderfunktionen wird übrigens die Seitensuche unterbrochen. Man sollte sie also nicht aufrufen, um sich gerade die Wartezeiten während der Seitensuche zu vertreiben. 5.2 Umschalten von Betriebsarten -------------------------------- t: Schaltet den Testmodus ein/aus, ausführliche Beschreibung s. o., im Abschnitt zur Inbetriebnahme. Wenn man das Programm momentan nicht benutzt, aber noch nicht verlassen will, sollte der Testmodus ausgeschaltet werden. Nur so kann sich das Programm in den Multitasking-freundlichen Wait-Zustand begeben, sonst wird immer noch weiter Rechenzeit verbraucht! f: Schaltet zwischen den drei möglichen Formaten für die Ausgabedatei um: 1. reiner ASCII-Text (für Weiterverarbeitung/Druckerausgabe) 2. rohes VT-Format (falls Farbe/Grafik erhalten bleiben sollen) 3. IFF-Bild (nicht so kompakt wie das VT-Format, dafür aber nicht mehr auf "VTview" und den "videotext.font" angewiesen) m: Schaltet um zwischen den Dateimodi "Überschreiben" und "Anhängen". Wenn "Überschreiben" gewählt ist, erfolgt vor jedem Speichervorgang noch eine Sicherheitsabfrage. Wenn "Anhängen" gewählt ist, entfällt diese Abfrage, und es wird lediglich grob überprüft, ob das Anhängen sinnvoll ist. Das sieht dann so aus, daß der Speichervorgang einfach verweigert wird, falls die ausgewählte Datei als IFF- oder Programmdatei erkannt wurde. ABER: Natürlich gibt es außer 'IFF' und 'Programm' unzählige weitere Dateitypen, wie Archive, Icons usw., die es extrem übel nehmen, wenn man irgendwelchen Müll an ihr Ende anhängt. All diese kann VIDEOTEXT unmöglich erkennen (und soll es auch gar nicht), darum Vorsicht, auch beim Anhängen an Dateien! p: Funktioniert die Datei zur Protokolldatei um (und wieder zurück). Dieser Modus ist nur sinnvoll, wenn sich gerade eine Untertitelseite in der Seitensuche befindet. Jeder neue Inhalt einer solchen Seite wird dann als ASCII-Text an die Ausgabedatei angehängt. Dabei werden nur die Zeilen ausgegeben, die das Box-Attribut tragen, also der Teil der Seite, der am Fernseher als Untertitel eingeblendet würde. Genau die Funktion, die früher der Untertitelsammler (UTS) erfüllte, nur daß der den Decoder komplett blockierte. F1,F2,F3: Steuern die Bildschirmdarstellung des Videotext-Decoders: Vollbild/transparent/aus. Nur von Bedeutung, wenn der SAA 5246 auch mit R, G, B und BLNK an den SCART-Eingang eines Fernsehers angeschlossen ist. 5.3 Seitenanforderung --------------------- Einfach Seitennummern eintippen (mit Return abschließen), und sie werden in die Job-Warteschlange eingereiht. Für Korrekturen kann die Backspace-Taste ("<-") verwendet werden (Vorsicht, nicht mit "Del" verwechseln, s. u.). Wenn die Eingabe gelegentlich stockt, so liegt das daran, daß während des Einlesens von Seiten keine Tastaturabfrage stattfindet, erkennbar auch am Mauszeiger, der zur Stoppuhr wird. Das Problem ist seit Version 3.4 mit der schnelleren Assembler-Busroutine aber erheblich entschärft. Außer einfachen Seitennummern wie 100, 572 und 525 kann man auch einzelne Unterseitennummern eingeben, z. B. 100/7 und 642/1. Die übliche Anwendung dieser Unterseiten-Direktwahl ist der Ersatz einzelner Unterseiten, wenn sie bei der Übertragung beschädigt wurde. Alle anderen Fälle lassen sich einfacher regeln, indem man die Seite komplett einliest (einfache Seitennummer eingeben) und die unerwünschten Unterseiten anschließend von Hand löscht. Es ist insbesondere Verschwendung, mehr als eine Unterseite ein und derselben Seitennummer einzeln anzufordern! Jede Unterseite beansprucht dann einen Empfangskreis des VT-Decoders für sich, und von denen gibt es beim SAA 5246 bekanntlich nur vier. Bearbeiten der Warteschlange: +,-: Bewegen einen >Auswahlzeiger auf eine Seitennummer, wobei es egal ist, ob diese sich noch in der Warteschlange befindet oder bereits in die Seitensuche aufgerückt ist. Der Auswahlzeiger ist intelligent genug, einer Seitennummer zu folgen, anstatt starr auf einen bestimmten Platz in der Warteschlange zu zeigen. *: Irrtümlich eingegebene Seitennummern können mit dieser Taste nachträglich aus der Warteschlange entfernt werden. <Del> oder <BS> wären für diese Funktion vielleicht naheliegender gewesen, aber die hatten bereits andere Bedeutungen, und immerhin liegt '*' auf dem Ziffernblock direkt über '+' und '-'. Außerdem kann man sich als Eselsbrücke den * als kleine Explosion vorstellen ;-) Wichtig ist diese Funktion außerdem für Untertitelseiten: ein Job, der als Untertitelseite erkannt wurde, kann nämlich nicht mehr automatisch aus der Seitensuche rausfliegen, nicht einmal durch Zeitüberschreitung. Hier muß der Benutzer selbst eingreifen. u: Ernennt eine Seitennummer zur Untertitelseite bzw. entzieht ihr diesen Status wieder. Hm. Hatte ich nicht gerade schon erwähnt, daß das Programm selbst erkennen kann, was Untertitelseiten sind und was nicht (und zwar an einem Statusflag vom Sender)? Was soll dann diese Option? Die automatische Erkennung überstimmen kann sie schonmal nicht: Eine Seite verliert nämlich den (vermutlich zu Unrecht zuerkannten) Untertitelstatus automatisch wieder, wenn sie zweimal hintereinander ohne das entsprechende Statusflag eintrifft. Nein, der Zweck liegt vielmehr in folgendem: Untertitelseiten sind wie erwähnt von der Überprüfung auf Zeitüberschreitung befreit, so daß sie auch während längerer Pausen in der VT-Untertitelung nicht aus der Seitensuche entfernt werden. Aber angenommen, man fordert die Untertitelseite an, noch bevor die untertitelte Sendung beginnt. Die Pause bis zum ersten Untertitel kann dann ebenfalls leicht die festgesetzte Zeitschranke (typ. 60 - 90 sec.) überschreiten, nur woher soll das Programm in dem Fall wissen, daß es auf eine Untertitelseite wartet? Aha - indem man es ihm einfach sagt, mit 'u'. Funktioniert nur für Seiten, die bereits in der Seitensuche stehen, das dürfte aber keine ernsthafte Einschränkung sein. F9: Löscht wie '*' ebenfalls Jobs, nur etwas radikaler, die *gesamte* Warteschlange inclusive der Seitensuche wird gelöscht. 5.4 Konfigurationsdatei ----------------------- Ist Ihnen vielleicht schonmal aufgefallen, daß Sie manche Seitennumern häufiger eintippen als andere? Z. B. die Seiten 112, 113, 114, 115 mit dem Nachrichtenüberblick auf ARD/ZDF, die Seite 555 mit dem Tagesspruch auf West 3? Sie können Tipparbeit sparen, indem Sie eine Konfigurationsdatei mit Ihren Lieblingsseiten der einzelnen Sender anlegen. Pro Sender können max. so viele Seiten eingetragen werden, wie auf einmal in die Warteschlange passen, d. h. momentan 19, nicht übel. Das Dateiformat ist einfach: ASCII-Klartext mit einer Seitennummer pro Zeile, die Zuordnung zu den Sendern erfolgt durch ein vorangestelltes Stichwort, das in der Videotext-Kopfzeile des jeweiligen Senders vorkommt (wird dadurch als Stichwort erkannt, daß es andere Zeichen außer Ziffern und '/' enthält, also keine Seitennummer sein kann). Leerzeilen sind zur besseren Lesbarkeit der Datei zugelassen, tragen aber keine Bedeutung. Beispiel für eine Konfigurationsdatei: ARD/ZDF 100 250 252 253 525/1 SAT.1 500 540 543 MTV 102 103 110 112 Die Konfigurationsdatei wird unter dem Namen "VT.config" gesucht, zunächst im aktuellen Verzeichnis, und wenn sie dort nicht ist, anschließend in S:. Fehlt nur noch das wichtigste: Mit F10 wird die Konfiguration aufgerufen. Dabei ist es ganz ratsam, die Warteschlange zuvor mit F9 zu löschen, evtl. auch mit F8 den Seitenspeicher. 5.5 Die eingelesenen Seiten --------------------------- Die Nummern der eingelesenen Seiten sind sortiert spaltenweise in einer Übersichtstabelle dargestellt. Diese Tabelle kann man durchblättern, sie wird gescrollt, wenn sie nicht vollständig auf den Bildschirm paßt. Die hier ausgewählte Seite wird angezeigt, sie kann auch abgespeichert oder gelöscht werden. Crsr ^/v: Eine Seitennummer vorwärts/rückwärts. SHIFT-Crsr ^/v: Ein Magazin (100er-Gruppe) vorwärts/rückwärts. Es wird die niedrigste Nummer im nächsthöheren/-niedrigeren Magazin angesteuert. Crsr <->: Eine Spalte vorwärts/-rückwärts springen. ?: "Rätseltaste", in der momentan angezeigten Seite werden die verdeckten Zeichen aufgedeckt. Space: Die verdeckten Zeichen wieder tarnen. Auch verwendbar, um einen Refresh zu erzwingen (z. B. nach Löschen einer Seite, oder wenn man einen Seitenaufbau durch Eintippen eines Jobs unterbrochen hat, etc.). Del: Die angezeigte Seite wird aus dem Speicher gelöscht. Damit man auch merkt, was man gerade getan hat, wird nicht nur ihre Nummer aus der Tabelle entfernt, sondern auch eine leere Bildschirseite ausgegeben. F8: *Alle* im Speicher befindlichen Seiten werden gelöscht. Zum Glück gibt es aber zuvor noch eine Sicherheitsabfrage. s: Die angezeigte Seite speichern, je nach eingestelltem Format als ASCII, VT oder IFF, s. o. Funktioniert nicht, während die Datei als UT-Protokolldatei arbeitet. n: Neuen Dateinamen festlegen, hierzu erscheint ein Filerequester. Falls die req.library nicht vorhanden ist, müssen Sie stattdessen einen Namen einfach so eintippen :-(. 5.6 Programmende ---------------- Tippen Sie "x", und nach einer Sicherheitsabfrage, die Sie mit "j" beantworten, wird das Programm beendet. Alternative: das Pulldown-Menue mit dem Menuepunkt "Quit" (ein Stückchen Intuition-Oberfläche muß schließlich sein!), wobei die Sicherheitsabfrage allerdings entfällt. 6. Argumente beim Programmstart =============================== VIDEOTEXT unterstützt CLI-Parameter und Workbench-ToolTypes. Zunächst die ToolTypes: FILE=<name> Namen der Ausgabedatei festlegen. (Kann vom Programm aus jederzeit über Filerequester geändert werden.) Beispiel: FILE=RAM:VTdatei MAXWAIT=<seconds> Die Zeit, nach der angenommen werden soll, daß eine angeforderte Seitennummer nicht existiert. Ein vernünftiger Wert sind ca. 60-90 Sekunden. Beispiel: MAXWAIT=60 BUSDELAY=<loops> Das Timing des I²C-Bus ist absolut unkritisch, solange 100 kHz Taktrate nicht überschritten werden. Leider ist meine IO-Routine, seit sie in Assembler geschrieben ist, schnell genug, um diese Taktrate auf Standard-68000er Amigas gerade eben zu erreichen, und sie dafür auf allen anderen Modellen (A3000, A1200, A4000) gnadenlos zu überschreiten. Wenn nun darum Busprobleme auftreten (s. o., Inbetriebnahme), können mit BUSDELAY in jedes übertragene Bit kleine Warte- schleifen eingebaut werden. Vorgehensweise, um den richtigen Wert zu finden: - Zunächst eine riesige Zeitschleife bauen, BUSDELAY=500. (Das *muß* einfach klappen, z. B. selbst ein 68040, der es irgendwie schafft, die Schleife mit 40 MIPS im Cache abzuarbeiten, könnte danach höchstens noch 40 kbit/s übertragen.) Wenn das nicht hilft, sind die Busprobleme ziemlich sicher von der I²C-Hardware verschuldet. - Danach beobachten, wieviele Sekunden es dauert, eine Seite einzulesen (wie lange wird der Mauszeiger zur Stoppuhr) - Berechnen, welcher Wert für <loops> eine Einlesezeit von ca. 0.2 Sekunden ergeben müßte. Beispiel: BUSDELAY=500 ergibt auf Ihrem Rechner eine Einlesezeit von 6 sec: der korrekte Wert wäre dann 500 / 6 * 0.2 = 16. Beispiel: BUSDELAY=0 BURST=<tics> SHUFFLE=<tics> Timing-Parameter für die Seiteneinleseroutine, Einheit: 1/50-Sekunden. Veränderungen hieran brauchen lediglich vorgenommen zu werden, wenn öfters unvollständige Seiten eingelesen werden, und zwar unvollständig in dem Sinne, daß ein paar der *untersten* Zeilen fehlen (d. h. die Seite war zum Zeitpunkt des Einlesens in den Amiga noch nicht vollständig im Decoder eingetroffen). Andere Fehler, wie mittendrin fehlende Zeilen oder Zeichen sind *nicht* mit diesen Parametern behebbar! Die zwei Parameter werden alternativ verwendet, für zwei verschiedene zulässige VT-Ausstrahlungsprotokolle. Dabei scheint das Verfahren "serielle Magazinfolge" (BURST) das allgemein üblichere zu sein. Das Programm signalisiert diesen Modus, indem die Unterseitennummer, die es oben links in jede VT-Seite einträgt, in runde Klammern setzt, (0000). "Verschachtelte Magazinfolge" (SHUFFLE) trifft man aber auch gelegentlich, z. B. beim "Children's Channel", angezeigt wird dieser Modus durch spitze Klammern um die Unterseitennummer, <0000>. Das Problem, das diese Parameter überhaupt nötig macht, ist folgendes: Eine Videotextseite besteht bei der Übertragung aus einer Kopfzeile und einigen (normalerweise 23) Folgezeilen. Das Eintreffen der Kopfzeile wird in einem auslesbarem Flag im Decoder gemeldet, nicht aber das *Ende* einer Seitenübertragung. Also muß man einfach blind eine Zeit lang warten, und hoffen, daß die Seite anschließend komplett ist. Die gute Nachricht: im Burst-Modus ist die Seitenübertragung so schnell, daß man normalerweise überhaupt nicht warten muß (BURST=0), der leere Seitenspeicher wird nämlich ungefähr gleich schnell, eher sogar etwas schneller aufgefüllt, als er über den I²C-Bus überhaupt ausgelesen werden kann. Die schlechte Nachricht: der magazinverschachtelte Modus braucht ca. 8mal so lange für die Übertragung einer Seite. Zwar werden hier wie auch beim magazinseriellen Modus typischerweise ca. 13 Seiten/sec. übertragen, aber die Zeilen aus bis zu 8 verschiedenen Seiten (aus den 8 Magazinen) dürfen ineinander verzahnt gesendet werden. Kurzum: hier ist garantiert eine Wartezeit nötig, größenordnungsmäßig eine halbe Sekunde (SHUFFLE=25). Vorsicht: stellen Sie keine unnötig langen Wartezeiten ein, weniger als 1 Sekunde (d. h. <50) müßte immer genügen. Sonst kann es passieren, daß bis zum Beginn des Einlesens bereits ein neuer Seiteninhalt eintrifft, äußerst häßliche Situation. Beispiel: BURST=0 SHUFFLE=30 Hier nun die entsprechenden CLI-Parameter: -f=<name> Name der Ausgabedatei (das "=" ist optional) Beispiel: -f=RAM:VTdump -w<seconds> maximale Wartezeit für gesuchte Seiten Beispiel: -w60 -d<loops> Verzögerung der Busroutine Beispiel: -d0 -b<tics> -s<tics> Pause zwischen Eintreffen einer Kopfzeile und Beginn des Einlesens der Seite, bei Sendern im burst- bzw. shuffle-Modus Beispiel: -b0 -s20 und zusätzlich, nur vom CLI aus: <page> <page> ... Alle Argumente, die nicht mit "-" beginnen, werden als Seitenanforderungen interpretiert und, sofern sie eine gültige Seitennummer darstellen, in die Warteschlange eingereiht. Beispiel: 100/1 112 113 114 115 7. Dienstprogramm VTview ======================== "VTview" liest von "VideoText" im VT-Format erzeugte Dateien und dient dem Betrachten der darin enthaltenen Videotext-Seiten. Es benötigt dazu (wie "VideoText" selbst) den Font "videotext/9". Die Seiten werden diesmal auf einem LoRes-Bildschirm (und nicht MedRes) dargestellt, was der Wirkung nach eher dem original Fernseh-Videotext entspricht. Es können beliebig viele Eingabedateien übergeben werden, entweder von der Workbench aus durch Extended Select bzw. über Default Tool, oder in Form von CLI-Parametern. Die Dateien müssen mit dem Schlüsselwort "VTPG" beginnen, unterliegen ansonsten aber keinen besonders strengen Formatanforderungen. Z. B. können sie VT- und ASCII-Format gemischt enthalten (auch wenn das nicht viel Sinn macht), es werden dann halt soviele VT-Seiten ausgelesen, wie identifiziert werden können (Schlüsselstring für VT-Seiten: "VTPG\n"). Die Seiten werden intern zu einer einzigen Liste zusammengesetzt, wobei aber im Gegensatz zum Hauptprogramm keine Sortierung vorgenommen wird, und Seitennummern dürfen auch doppelt vorkommen. Über ToolTypes oder CLI-Parameter können noch diverse Einstellungen vorgenommen werden. Zunächst die CLI-Parameter: -a[uto]: Normalerweise blättert man die Seiten von Hand durch (Crsr ^/v: seitenweise, Shift-Crsr ^/v: magazinweise), mit diesem Flag wird dagegen eine Art Diashow aktiviert, die alle eingelesenen Seiten nacheinander anzeigt. Durch beliebigen Tastendruck wird die Kontrolle aber an den Benutzer zurückgegeben, ESC beendet das Programm ganz. -c[ycle]: Normalerweise endet VTview, wenn im Diashow-Modus das Ende der Seitenliste erreicht wird. Mit diesem Flag erzwingt man dagegen eine Endlos-Schleife. Wie die gewöhnliche Diashow endet auch diese Schleife auf Tastendruck hin. -r[eveal]: Wie im VideoText-Programm können verdeckte Zeichen mit '?' aufgedeckt und mit ' ' wieder verdeckt werden. Bei Diashows nutzt das natürlich nicht viel, darum kann mit diesem Flag die Anzeige des verdeckten Textes global, für alle Seiten, erzwungen werden. -t<secs>: Gibt an, wieviele Sekunden jede Seite in Diashows angezeigt bleibt. Default-Wert ist 2. Noch schnell ein Beispiel: VTview ARD-ZDF TNT -c -t3 Bei den korrespondierenden ToolTypes ist noch zu beachten, daß man zu jedem beteiligtem Icon, also zu jeder Seitendatei und sogar zu VTview selbst, ToolTypes angeben kann. Welche gelten dann? Regel: Es werden zuerst die ToolTypes von VTview selbst ausgewertet, danach die ToolTypes der Dateien, in der Reihenfolge, wie sie angeklickt wurden. Die später ausgewerteten überstimmen dabei die vorangehenden. Damit das auch für alle Optionen möglich ist, existieren zu jedem Flag mindestens zwei Alternativen: MODE=MAN|AUTO|CYCLE FLAGS=REVEAL|CONCEAL TIMING=<secs> Beispiel für einen sinnvollen Eintrag: MODE=AUTO FLAGS=CONCEAL TIMING=3 8. Benutzungsbedingungen ======================== VIDEOTEXT ist Freeware, das heißt, es darf beliebig kopiert und weitergegeben werden, solange die zugehörigen Dateien VideoText VideoText.info VTview VTview.info videotext.font videotext/9 LiesMich Hardware.doc Versionen.doc unverändert beieinander bleiben. Ansonsten, würde ich mich über Meinungen und Anregungen zum Programm freuen. Schreiben Sie mir, - wenn Sie Fehler gefunden haben, z. B. daß das Programm unter Kickstart 1.3 gar nicht wirklich funktioniert, - was Sie von meinen weiteren Plänen für VIDEOTEXT halten (siehe Textdatei "Versionen.doc"), - was Sie tun mußten, um das Programm auf Ihrem xx MHZ/680x0-Amiga zum Laufen zu bringen, - was sich an der Dokumentation verbessern läßt, - welche vergleichbaren Videotext-Programme es gibt und was diese können ("TeleText" von Jan Leuverink kenne ich schon, sonst keine), - welche Varianten von I²C-Bus-Interfaces am Amiga es gibt (und wie man sie ansteuert?), - oder einfach, daß ich ein schönes Programm geschrieben habe :-) Meine Adresse: Wilhelm Nöker Hertastr. 8 D-44388 Dortmund Auch kleine Spenden (d. h. <DM 20), um einem armen Studenten bei der Finanzierung eines CD-ROMs zu helfen, sind stets willkommen. (Vergessen Sie diese Bemerkung ab ca. Mitte 1995, da ich dann wahrscheinlich eigenes Geld verdiene.) 8.1 Der Quelltext ----------------- VideoText ist für die neuen 2.0-Includefiles von KICK-Pascal geschrieben. Zwar benutzt es keine OS2-Funktionen, es mit den alten Includefiles zu kompilieren (die von Jens Gelhar selbst, nicht von Roger Fischlin), dürfte trotzdem schwerfallen. Ein Beispiel nur: ich rufe Funktionen aus der "misc.resource" auf. In den alten Includefiles ist die "misc.resource" aber noch gar keine Library, sondern besteht nur aus ein paar Konstanten- Definitionen. Wenn Sie Änderungen am Programm vornehmen, auch wenn Sie diese für von allgemeinem Interesse halten, bitte geben Sie keine derart gepatchten Versionen weiter. Es reicht, wenn einer an VideoText arbeitet (nämlich ich), weil es dann wenigstens immer eine eindeutig neuste Version gibt. Schreiben Sie mir also, und ich werde Ihre Änderungen (zugegeben: vielleicht) in die nächste Hauptversion einbauen. Falls Ihnen daß zu umständlich ist, machen Sie Ihre Version wenigstens deutlich als gepatcht erkennbar, bevor Sie sie weitergeben! Noch kurz zur Modularisierung des Projekts, d. h. zur Hierarchie der Units, und was ich mir dabei gedacht habe: global i2c_serial / | \ / | pagelist decode cct sys | \ | | | | | | \ | bildschirm | | \ X___ ___/ | jobs datei | \____ ______/ startup HAUPTPROGRAMM VIDEOTEXT Das gräßlichste am Compilieren sind immer die Include-Dateien. Bei der Modularisierung habe ich darum angestrebt, die Systemaufrufe in möglichst wenige Units zu konzentrieren: Lediglich "sys", "i2c_serial" und "startup" enthalten Includefiles. Alle anderen Units compilieren sich blitzschnell! Aber Vorsicht. Wenn man am INTERFACE-Teil (nicht der IMPLEMENTATION) eines Units etwas ändert, müssen alle davon abhängigen Units neu compiliert werden (keine Sorge, der Compiler meldet das schon). Z. B. bei einer Änderung im Interface von "global" alle (!) außer "sys" und "i2c_serial"! Dies Diagramm hilft dann wenigstens, eine sinnvolle Reihenfolge des ganzen Neucompilierens zu finden (z. B. global, pagelist, decode, cct, bildschirm, datei, jobs, startup). Wer so ein komplettes Neucompilieren des gesamten Projektes einmal mitgemacht hat, wird wahrscheinlich wünschen, daß es doch bitte, BITTE nicht ganz so viele Units wären? Nun ja, "bildschirm" und "datei" ließen sich vielleicht noch zu "ausgabe" zusammenfassen, obwohl das schon ein ziemlich riesiges Unit würde. Nur "decode" dann auch noch in "ausgabe" zu integrieren, wäre endgültig nicht mehr so toll, da "decode" als eigenständiges Unit wertvoller ist (nämlich wiederverwendbar für VTview). Das gleiche Argument spricht auch dagegen, etwa "pagelist" in "jobs" zu integrieren.